For those interested, here is a way to install Debian and boot it with UEFI if you have an UEFI motherboard. Using UEFI with Debian requires expert knowledge so if you do not feel up to it, keep your BIOS system. 1 Background UEFI is a specification for motherboard's firmwares which is replacing the old BIOS. For now, UEFI motherboards still include a BIOS compatibility layer. The UEFI boot process is quite different from the BIOS one. It involves one specific piece of the motherboard's firmware, the UEFI Boot Manager, which is able to load boot loaders from FAT file systems on specially-typed partitions. It can offer a boot menu (boot: Debian from HDD, Windows from HDD, USB stick, DVD?), which can be configured from a running operating system. So, basically, to boot a system with UEFI, you need two things:

• to install an UEFI boot loader on a FAT-formated EFI System Partition;
• to tell the UEFI Boot Manager to create an entry for that boot loader.

2 Installation or preparation If you are installing a new Debian system, read the first part. If you already have a BIOS-bootable Debian system installed, read the second one. In both cases you will have to use Debian testing, because stable's GRUB has problems with UEFI. You can also use Debian stable while taking only GRUB from testing though. 2.1 Installation of a new Debian system There is no installer image for UEFI, so you can either:

• make your own, by installing an UEFI boot loader to an USB stick, which will load a regular installer kernel and initrd;
• use a regular BIOS installer image, using the compatibility mode of your motherboard.

The installer does not provide a convenient way to install an UEFI boot loader, so you are going to install a regular BIOS boot loader at first, and switch to UEFI later. Use the expert mode and format your hard drive with a GUID Partition Table (GPT). Create a small partition (1 MiB would be far enough), type it as a BIOS Boot Partition (this is the untitled flag above the bootable one in Partman), do not format it and do not mount it: this will be needed for BIOS booting. Create another small partition (same kind of size), type it as an EFI System Partition (this is the bootable flag), format it as FAT and mount it on /boot/efi: this will be needed for UEFI booting. Finish the installation as usual, installing GRUB for BIOS, and boot your new system. 2.2 Preparation of an existing Debian system for UEFI You need to use a GUID Partition Table on your hard drive. If you used an MBR, you lost; you may try to convert it to GPT using a tool such as gdisk, but that means operating without a net, loosing your current boot loader in the process. If there is no space left on your hard drive, use Debian Live to make some. Create a small partition (1 MiB would be far enough), type it as an EFI System Partition, format it as FAT and mount it (permanently, using the fstab) on /boot/efi (that directory will not exist, so create it first). 3 Switch to GRUB UEFI Install the package grub-efi-amd64. Prepare it by running the command (assuming your hard drive is /dev/sda):

# grub-install /dev/sda

That will do three things:

1. generate a GRUB image;
2. install it to the EFI partition at efi/debian/grubx64.efi;
3. try to configure the UEFI Boot Manager (the motherboard's boot menu) to load it on start-up

That last step will fail. This is expected, because the UEFI Boot Manager can only be configured from an operating system that was started from UEFI. So if you stop here, you get an unbootable system. Now, copy (a symlink would be relevant here, but that cannot be done on a FAT file system!) the GRUB image to that other path on the EFI System Partition: efi/boot/bootx64.efi. This is where the UEFI firmware looks for a boot loader when it has not been configured for a specific path, typically on removable media. Reboot to check that If that trick worked, you are now on UEFI-booted system. Run grub-install again, which should now succeed to configure the UEFI Boot Manager. Reboot to check that you get a debian entry on the motherboard's boot menu, and remove efi/boot/bootx64.efi which is no longer needed.

Since some years, there has been a movement towards standardization: mobile devices are now using Micro-USB for data transfer and charging, and SD or Micro-SD for storage extension (except Apple of course). One piece is lacking to this perfection, however; as far as I know, digital camera producers did realize that SD won for storage, but they do not seem to have acknowledged the Micro-USB standard yet. Now, since manufacturers and resellers do not indicate the connector type, I have no way to be sure that this is still the case. So, dear lazyweb, do you know if, by chance, there exists a compact digital camera that would use SD cards and a Micro-USB connector for data transfer and integrated charging?

Unix rocks, or at least one of its design feature does: everything is a file. Here is one funny use of that feature. I consider that programs that manipulate text should basically take it on their standard input, and write it to their standard output, while specifying the name of an input or output file should be an optional refinement. Well, at least one program was designed the other way: when used to import a foreign key, ssh-keygen -i has no option to read it on its standard input. No problem, this can be worked around:

# ssh-keygen -if /dev/stdin
[paste the foreign key here]

Unfortunately, that does not work with every action of ssh-keygen since not all of them were written to be able to handle streams, which cannot be rewound.

Many websites have addresses that use a www.- prefix. Some people are encouraging this practice, other are advising against it. I, for one, think this prefix makes sense and is really useful, so here is an explanation of my opinion. In a nutshell: the Wold Wide Web is one Internet service among many other such as domain name, mail, mailboxes or instant messenging; using a dedicated prefix allows to distribute all these services to specific servers in a convenient way.On Internet, you can expose several services, the most common being domain names (DNS), websites (HTTP), incoming mail (SMTP), outgoing mail submission (submission), mailbox fetching (POP) or consultating (IMAP) and instant messenging (XMPP). Constraints Modern Internet services can have constraints such as load balancing, failover and most importantly the possibility to use specific servers for each service instead of having all of them on the same server. Dedicated records Some service were designed or revised to take these contraints into account; this include the domain name, incoming mail and instant messenging, by using dedicated DNS records:

example.com.                    NS              roquefort.example.com.
example.com.                    MX  10          morbier.example.com.
_xmpp-server._tcp.example.com.  SRV 10 100 5269 morbier.example.com.

In that example, the name service of example.com. is provided by the server Roquefort while the incoming mail and instant messenging service are provided by Morbier Dedicated prefixes On the contrary, some services were not designed to take these constraint into account, and may be too fossilized to be revised for that; this includes the Web and mailbox service. A convenient way to work around the antiquated design of these services is to use a well known prefix:

www.example.com.                CNAME           ossau-iraty.example.com.
smtp.example.com.               CNAME           morbier.example.com.
pop.example.com.                CNAME           morbier.example.com.
imap.example.com.               CNAME           morbier.example.com.

In that example, the Web service of example.com. is provided by the server Ossay-Iraty while the email submission and mailbox services are provided by Morbier. Readability and flexibility Using dedicated records and prefixes increases the consistency and readability of a DNS zone, since it allows to refer to the servers by their canonical host name, and to define their IP addresses once and for all:

; Services
example.com.                    NS              roquefort.example.com.
example.com.                    MX  10          morbier.example.com.
pop.example.com.                CNAME           morbier.example.com.
imap.example.com.               CNAME           morbier.example.com.
www.example.com.                CNAME           ossau-iraty.example.com.
; Hosts
roquefort.example.com.          A               192.2.0.12
                                AAAA            2001:db8::12
morbier.example.com             A               192.2.0.42
                                AAAA            2001:db8::42
ossau-iraty.example.com.        A               192.2.0.51
                                AAAA            2001:db8::51

You can think of that practice as connecting dots between services and hosts:

name service    Roquefort
incoming mail   Morbier
mailboxes         Ossau-Iraty
website        

With such a DNS zone, it is very easy to identify which server is hosting each service. Using host names rather than IP addresses multiple times reduces the information duplication, which in turn facilitates future chances and reduces the risk of error (it is easier to swith the website from Ossay-Iraty to Morbier than from 192.2.0.51/2001:db8::51 to 192.2.0.42/2001:db8::42).

Summary The JSON License may seem interesting, but it a bad license, both non-free and ambiguous: do not use it. If you are the author of a piece of software that uses JSMin or its PHP port, consider dropping that non-free part or at least rendering it optional.The JSON license Do you know the JSON License? It is a software license inspired by the MIT/Expat license with one additional morality clause:

The Software shall be used for Good, not Evil.

Non-free For novices that clause can be perceived as a good idea serving a noble goal. But the problem here is that is would make your software non-free. Indeed, there are two common definitions of free software: the FSF definition, and the Debian Free Software Guidelines, also known as the Open Source Definition. Basically, both definitions indicate that to be free, a piece of software must be usable with no restrictions, and forbidding evil uses is such a restriction. Specifically, it violates:

• the FSF's zeroth liberty: A program is free software if the program's users have the four essential freedoms: The freedom to run the program, for any purpose (freedom 0). [ ]
• the DFSG/OSD sixth point: No Discrimination Against Fields of Endeavor: The license must not restrict anyone from making use of the program in a specific field of endeavor.

Ambiguous In addition to these incompatibilities to being free, this morality clause implies additional problems, the most important one being that it is ambiguous, which is very bad for a license clause: who exactly defines what is Good and what is Evil? If it is the author, then this clause could be used for arbitrarily forbidding any use; it it is the licensee, then this clause it as good as void. Do not use it For all these reasons, the JSON License with that infamous morality clause is not suitable for free software, so if you plan to use that license for your work, please consider these suggestions: 1. do not; 2. do not, really; 3. if still in doubt, refer to point 1. There are several standard free software licenses, the closest one being the MIT/Expat one, that you should consider instead. Now, if you really want to be considered as non-free, and rejected by Debian, Red Hat/Fedora, Google Code and more generally any free software distributor, this is the way to go. On thing worth noting is that this morality clause only annoys free software distributors, that are certainly not doing Evil, but will not prevent any evil person to do Evil things with your software. To encourage people to do Good rather than Evil, it would be better to formulate that clause as a suggestion rather than an order:

The Software should rather be used for Good, not Evil.

The JSMin case This infamous JSON License is known to be used by JSMin and its PHP port. If you are a Web application author, be careful when embedded external content, since it can render you whole piece of software non-free! If you are using JSMin, I would suggest that you drop it, or at least make it optional by using a conditional (if JSMin is here, use it, otherwise do nothing) so that distributors such as Debian can expurgate that non-free part.

For hurried readers: do not give your main email address to Moneybookers or to deviantART, since they may give it (unintentionally, I hope) to spammers.Dedicated addresses Since I have set up my own email server, when a company or an unknown individual asks for an address I give it a dedicated one. For instance, to make a payment I had to give an address to Moneybookers: instead of giving them my main address <tanguy@>, I used <tanguy+moneybookers@>. Thanks to Postfix's address extension feature (look for recipient_delimiter in postconf(5) manpage), these <tanguy+whatever@> are all implicit aliases to my main address. This practice has several benefits, since it allows me to:

• easily sort messages to dedicated mailboxes;
• identify who sold or gave away my address to spammers when I start receiving tons of spam to <tanguy+moneybookers@>;
• easily block that kind of spammers.

Working around lamers Some systems are coded by lamers that think the + sign is forbidden for email addresses, so I have to work around that. My current solution it to use a static alias <tanguy-2012@>, which I simply drop after a year to replace it by a new one. Two years report After two years collecting spam, the first noticeable thing is that, among 5.5k spams I received, only 78 are the result of an information leak from an organization. I excluded from that count the addresses I use in public mailing-lists, for instance <tanguy+debian@>. So, after some fine exclusion and checking of messages, these are the only two organizations that somehow gave my address to spammers:

1. Moneybookers: 43 spam messages received;
2. deviantArt: 35 spam messages received.

To use an SSH agent, one usually has to:

1. launch the agent;
2. add his key to it.

The first step can be automated in the desktop or shell startup script (this is a typical use case for login shell-only startup scripts, by the way), but the second one cannot if your private key is protected by a passphrase.Opportunistic key loading GNOME Keyring includes an SSH agent which has an interesting feature I call opportunistic key loading : it asks for the passphrase to decrypt the private key the first time it is needed. This feature mimics the behaviour of PGP agents, and eliminates the second step I previously mentioned. Question Do you know if there exists another SSH agent able to do opportunistic key loading?

The last versions of OpenSSH brought an interesting feature: sharing multiple sessions over a single connection. When enabled, this is how it works:

1. The first time you open an SSH connection to a server (including anything that works on top of SSH, like SCP, SFTP, rsync or Git), it opens a network connection as usual. It also opens a local Unix socket and listens to it for later use.
2. The next times you open an SSH connection to that server while the first one is still open, instead of opening a new network connection, it connects to that local Unix socket and lets the first SSH client carry its new session.

Advantages

• By reusing an existing connection, it saves file descriptors, thus power, baby seals and kittens, and most of all it is faster than opening new ones.
• It does not require a new authentication, so it saves you the time to type your password or you key passphrase, and the time for the challenge-response to take place.
• Since you do not have to authenticate again, you can take advantage of you shell's power features to auto-complete remote paths for SCP, SFTP or rsync over SSH. That is, if you use a powerful shell, of course.

Disadvantages Just like SSH agents, there is one major side-effect to take into account: new remote sessions can be opened without a password. Never use such a feature on a public computer if you are used to temporarily leave running sessions: here, locking them would not protect other people to get a shell access to your remote account! Configuration In ~/.ssh/config or /etc/ssh/ssh_config:

ControlPath ~/.ssh/control-%r@%h:%p
ControlMaster auto
ControlPersist 1

ControlPath

The name template for the session sharing Unix sockets. See the ssh_config(5) manpage for the syntax.

ControlMaster

Lets the SSH client use the session sharing socket if it exists or create it and listen otherwise.

ControlPersist

Usually, the first client to a given server is in charge of the connection sharing. It will then stay in foreground even if you terminate the session it is used for, until every other clients using its socket has finished, and forcefully terminating it will have the effect of terminating these clients! With that option, the master connection is put in background and will only terminate when no client needs it any more (one second after that, in fact), and you will be able to terminate the first session without kicking the other ones.

Try it! Apply this configuration and connect several times to a single host, to see the difference

If you install Debian on a computer with an AMD graphic card (an integrated Radeon HD 6310 in my case), you will only get garbage on your screen. Even without X.Org. This is because these graphic card require a non-free firmware to work, even in 2D with free drivers. So, boot with the kernel option radeon.modeset=0 to get a working console, then install the non-free package linux-firmware-nonfree. After that, do not forget to complain to AMD, because that really sucks hard. At the beginning there were microwave network cards unusable without non-free firmware, then wired network cards, and they are even invading graphic cards!

As a Debian administrator, power user or contributor, one often goes to look for information about a package, a bug, a developer or a message from the mailing lists. If you are in this case, you may be interested in the Firefox/Iceweasel extension Debian buttons , written by Damyan Ivanov and packaged by myself. Description When installed, this extension provides five buttons, that you can place in your Firefox or Iceweasel toolbar. These buttons take the text from the X11 PRIMARY selection and act as shortcuts to the web pages corresponding to:

• a package from the archive;
• the development of a package (Package Tracking System);
• a bug report (Bug Tracking System);
• a Debian Developer's packages (Developer's Packages Overview);
• a message from the mailing-lists.

Typical use case Let us imagine you see the following sentence on IRC:

12:42 < Tanguy> I am packaging a cool Firefox/Iceweasel extension (ITP #654896)!

If you want to check out the corresponding ITP report, just double-click on the bug number to select it (do not worry about the leading hash or even the possible trailing bracket, it will be handled), and click on the BTS button on your browser toolbar: here you are! Depending on your needs and habits, this extension may considerably speed up and simplify your quests for information. At least, it does for me, so I hope you will enjoy it too!

For this new year I got a quite specific present : a Debian Developer account. Of course this is not an end by itself but rather a beginning, or perhaps a continuation of my modest effort to contribute to the greater good of our users and free software. As an introduction, I would like to quickly explain how I came to this point, and I also have some people to thank.

Debianist journey

1997-2003

First family computer, a PC running Microsoft Windows 98. I became a power-user, and I progressively replaced all the pieces of that computer, except it operating system (though I reinstalled it several times).

2003

First contact with GNU/Linux: at my preparatory school, we use XEmacs and Kile under Mandrake Linux 9.2 to do some works in Caml Light and LaTeX. I start enjoying free software at home, with Mozilla Firefox, Thunderbird and Libre^WOpenOffice.org.

2005, preparatory school

I try Knoppix at home and eventually install Mandriva Linux 10.2 for my own use. Since then I have never used Microsoft Windows for personal work any more.

2005, engineer school

I integrate Centrale Paris and I join the team of VIA Centrale R seaux, which I believe is a known den of debianists. So I start using Debian on my personal laptop.

2006

Debian power-user. I start reporting bugs.

2007

First small contributions: some of my bug reports now include patches. I also start maintaining a French training document about Debian: formation Debian GNU/Linux.

2008

First packaging work with the help of adn, a modification and split of frozen-bubble to have a server-only package (contribution finally refused, actually).

2010

First package: I adopt dokuwiki with the help of adn. I become a Debian Maintainer, with the intent of applying as a Debian Member later.

2012

I am now a Debian Developer, responsible for a handful of packages and able to do NMUs and to sponsor new contributors.

As you may guess, I have always been a tinkerer, about computers but also about bikes (the ones that work with manpower, not the ones that make noise and smoke ;-)). And I also always wanted to publish my works somehow, because I hate to think that someone could have to do again some reusable work I had to do before instead of taking advantage of it. Well, it happened that free software was a way to achieve both goals: to hack and to make my work available for anyone. Thanks I would like to thank all those who helped me to discover and contribute to free software, especially: adn, who helped me with my first steps to directly contribute to Debian, dererk and all the Debian Developers that patiently reread and sponsored my packages, and my Application Manager gwolf, who gave quite a lot of time asking me questions, reading my replies, and replying to some questions that arose during the process. Outside of the Debian Project I have to thank Alexis de Lattre, who wrote the original Formation Linux that I am now maintaining under the name of Formation Debian GNU/Linux , a document which helped me to discover GNU/Linux and Debian specifically. More generally, I would like to thank all the Free Software community that made that possible: Debian Developers, hackers and users from everywhere. We have built and we are still building quite an impressive pile of very useful work, and we can be proud of it. Notes

1. Here in the northern hemisphere our school years begin in the middle of the civil year, which makes it tricky to tell them apart
2. This is almost a synonym for tinkering, in the context of free software, is it not?

I used to recommend the GNOME desktop for simple users for two main advantages over Windows:

• the logical, automatically filled and translated applications menu (compare that to the messy Windows Programs menu );
• the general interface consistency (compare that with Windows Explorer, Windows Media Player, Avast! and each piece of crap^Wsoftware whose author believed developing yet another custom interface was the way to go).

Both points are what I call calm advantages, because users will usually enjoy them without noticing. Instead, they will enhance their experience so that they will miss them when they come back to a system which does not provide these features. In fact, being used to that, I do not really consider these points as actual advantages, but rather as a bare minimum for any decent desktop and as very important lacks of some competitors.Well, GNOME 3 already reduced the first point by replacing the menu by a single loooong list of all the available software, although there are still categories at least. Now, with a recent upgrade, it appears that they destroyed the second one, the interface consistency. There used to be a thing called the GTK theme, that the user could choose according to his taste and needs, and all the GTK-based graphical software, including GNOME programs, used to follow that theme. This is no longer the case: now, for instance, Nautilus will look clear, while for some reason Eye of GNOME and Totem will look dark, with no option to make them look like the others.

Nautilus

Eye of GNOME

I used to be a GNOME user, but it has been some time since I stopped using a desktop at all and switched to a window manager that was more efficient according to my usage. However I kept using GNOME software, and I recommended GNOME to new users. Now it seems my arguments for that have reduced to a point where I should really consider recommending Xfce instead.

According to Eric S. Raymond, one rule for Unix programming is the Rule of Silence: When a program has nothing surprising to say, it should say nothing. Since return codes are a form of information, I would like to add: when a program has carried out its task with no surprise, it should exit(0).Take xscreensaver-command -lock, for instance. That command is meant to make a running XScreenSaver to lock the screen. I have never seen it fail in doing so, however I sometimes get a non-zero code:

% xscreensaver -lock
xscreensaver-command: could not frobnicate window 4212
zsh: exit 1   xscreensaver-command -lock

Well, xscreensaver-command, I have the deep regret to announce you that despite of your surprising return code, you successfully succeeded to lock my screen. But that return code is wrong and annoying. Wrong, because as a user, I do not care if xscreensaver-command -lock failed to frobnicate some window he would have loved to as long as it does its job and locks my screen. To the user's point of view, locking the screen is binary: either it is done and it is a success or it is not done and that is a failure. And it is annoying, because it makes the return code meaningless and prevents you from using it to do things like:

% # Lock screen and suspend to RAM (only if locking was successful)
% xscreensaver -lock && sudo pm-suspend

With xscreensaver-command sometimes returning a non-zero code with no apparent reason, you end with a locked screen and your computer still running, and have to unlock it and try again. This looks like this meaningless dialogue:

• Scott to bridge.
• Kirk here. Scotty, could you restore impulse power?
• I'm sorry captain, I was not able to align the coaxial stabilizers, we just sustained too much damage here.
• How long would it take to get that power back?
• But you have it captain! Impulse power is working all right, it's just that
• Good job Scotty, do you think will hold long enough?
• Well, I'd say it should hold until our next scheduled revision if we take care, but captain, I could not align

So please, when you write a utility, design your return code for the user, not for you. If your utility has done the job, it should exit(0). What happened inside does may interest you as the developer but it does not matter to the user as long as the job is done, so it should not be reported to him, especially not with a misleading failure code.

When someone wants to package a piece of software for Debian, he has to file an Intent to Package, by filing a special bug report against the pseudo-package wnpp (work-needing and prospective packages) with a title of ITP: software name . This way, we can synchronize our efforts, for instance if someone else wants to package the same piece of software. I have seen two recent examples of a misunderstanding of the correct use of such reports, so perhaps this reminder may be of some help for newcomers.While an Request for Package means that its author would like someone to package a piece of software, and ITP means that its author wants to package it himself and to have it integrated to Debian (in fact, an RFP also becomes an ITP when someone is willing to do the work). This means that the owner of an ITP bug is responsible for the corresponding work. Given that the ITP report is meant to inform others, that implies that he should document his progress by appending messages to the bug report. In particular, when something is blocking the work (typically a failure to find a sponsor), that should be indicated in the ITP report so that it does not appear as being abandoned. So, in a nutshell, when you have opened an ITP, do not expect someone to take it, to reply to it or whatever deus ex machina; you are now the owner of that bug, which means you are responsible of making it live and eventually closing it by sending your package to Debian. The progress of a packaging work should be documented, especially if it requires some specific help such as sponsoring, and the ITP report is the best place to do that since this is where interested people will look for status information.

Traditionally, when you start a program to view a document, for instance xpdf resume.pdf, it stays in foreground, and only returns when it finishes, when you are done with the document. Of course you can still run it in background if you want. Nowadays, several programs behave in a different way, for instance Evince. When you first start it, it stays in foreground as usual. However, if you launch it a second time while the first instance it still running, it will reuse this existing instance, asking it to open your document in a new window, and immediately return. Other examples are Firefox and LibreOffice.This behaviour is certainly more efficient in terms of memory usage and speed, but it is non-standard and causes subtle problems. When you open the attachment of an email message, or when you open a document from the Web without saving it permanently, the mailer or the browser saves the document to a temporary file, and then run a viewer with that file. As this is a temporary file, so they cannot leave it forever in /tmp; in fact they should delete it when you are done viewing it. I think the usual way to implement that is to delete it when the viewer returns: with a program that returns immediately, this means deleting it even before it has had a chance to load it. So, if you can no longer directly open a PDF attachment from Mutt, or if you are unable to view the compressed documentation of the LaTeX class Beamer with texdoc (which uncompresses it to a temporary file and calls a PDF viewer on it), you can blame your modern PDF viewer that returns before you are finished and start hacking your mailcap file. And if you are the author of such a program, please consider implementing a way to keep a lightweight process that does not return before the main process has closed the document or to disable process reuse.

Shell prompts are often designed to provide a reminder of useful context information such user name, host and current directory:

PS1="\u@\h:\w\$"
tanguy@muscat:~/public_html$

Such a prompt is sufficient to serve its original purpose, but it can be enhances in at least one useful way. Sometimes you have to copy the path of the current directory: with this prompt, it means selecting it by precisely dragging the mouse over it. Well, by adding spaces around the current directory you can become able to select it with a simple double click:

PS1="\u@\h: \w \$"
tanguy@muscat: ~/public_html $

Indeed, with such a prompt, you can now roughly point to the path, double click, and let your terminal emulator's word detection feature select the whole path for you. This simple modification may save you several tenths of seconds!

Both Bash and Zsh use several startup scripts: profile, bashrc, zlogin, zshrc, etc. The existence of several startup scripts exists to allow you to apply specific actions for interactive or login shells. For instance, you may want to set up a fancy colour prompt or to enable a powerful completion system for interactive shells only, as it would be pointless to apply it to non-interactive shells (that is, for shell scripts). Or you may want to display a joke and the weather forecast at login, but not each time you spawn a shell by other means.Common Both Bash and Zsh first execute a system-wide file, then the corresponding user-specific one. For instance, /etc/profile then ~/.profile. For simplicity I shall only mention the files' base names. Bash At startup, depending on the case:

• run as a login shell (or with the option --login), it executes profile;
• run as an interactive, non-login shell, it executes bashrc (the system-wide version is called bash.bashrc).

At exit, it executes ~/.bash_logout (no system-wide version). Note the funny (read: insane) non-login condition for executing bashrc: it is often worked around by having the profile execute bashrc anyway. Zsh Zsh always executes zshenv. Then, depending on the case:

• run as a login shell, it executes zprofile;
• run as an interactive, it executes zshrc;
• run as a login shell, it executes zlogin.

At the end of a login session, it executes zlogout, but in reverse order, the user-specific file first, then the system-wide one, constituting a chiasmus with the zlogin files. Summary

Bash

		login
		yes	no
interactive	yes	profile	bashrc
	no	profile	-

Zsh

		login
		yes	no
interactive	yes	zshenv zprofile zshrc zlogin	zshenv zshrc
	no	zshenv zprofile zlogin	zshenv

I personally find the Zsh process much saner. To be honest I should rather say that I find Bash's behaviour insane, with an absurd process (bashrc for interactive, non-login shells ) that needs to be worked around, and an inconsistent naming and search convention (~/.bashrc vs. /etc/bash.bashrc, no system-wide version of bash_logout).

Several modern complex file formats are based on a ZIP container: this is at least the case of OpenDocument and EPUB. However, they are not simply a bunch of files joined into an archive, but they follow some rules in order to be easily recognized by tools such as file. As I had to unpack, modify and repack such a container, here is a recipe to do that.The zip command is flexible enough to allow you to work in place (I am not sure that it is really in place) to add, remove and replace files in the archive, however I find it more convenient to work on the unpacked tree and repack later. Unpack and work To unpack, just unzip, being aware that these containers do not have a root directory, so it is better to extract them to a dedicated directory. Modify as you wish; if you add, remove or replace files, remember that there is a file list to modify accordingly: META-INF/manifest.xml for OpenDocument, OEBPS/content.opf and possibly OEBPS/toc.ncx for EPUB. Repack To repack, you must create a ZIP archive without extra file attributes, and put the file mimetype uncompressed in first position. Its goal is to be visible as plain text at a fixed position, to serve as a magic file type indication. The remaining files can be stored compressed and in random order. For an EPUB, for instance, this gives the following commands:

% zip --no-extra --compression-method store ../book.epub mimetype
% zip --recurse-paths ../book.epub META-INF OEBPS

This could be automated by a dedicated script, but I felt no need to write one yet. By the way, these options can be abbreviated as -X0 and -r.

rxvt-unicode is a terminal emulator with some interesting features. Here is one of them I find most amazing and elegant: it can generate the symbol characters corresponding to keyboard keys. It works by pressing and releasing + ( is the symbol for the Control key, and is Shift, of course), then the key which symbol you want to get. For instance, to get the Caps lock symbol, you type + , , which gives you the following symbol: . Here are some other nice examples: (Return) (AltGr aka Level3 Shift) (BackSpace) (Insert) (Delete) (Home) (End) (Prior) (Next). Beware that this will not cancel the effect of Caps, Num lock keys: you will get their symbols but also enter the corresponding mode.

I have just bought a new motherboard, a ASRock E350M1/USB3 with and embedded AMD E350 processor. I was mostly interested in trying the embedded GPU and the UEFI firmware (UEFI is simply the name of EFI 2). According to ASRock's marketing, the main benefit of that UEFI is its graphical interface that allows to use the mouse to configure the board. I cannot agree with that, because I think it is perfectly possible to implement that with a BIOS (and I think some BIOSes actually do it), and it is pointless anyway. For me, the main benefits are a faster and cleaner boot (no idea why it should be faster, but it is).The EFI boot process EFI seems to suffer from some (many?) design errors, but I find its boot process more clean and flexible than the old BIOS one:

1. It starts with a boot manager which is similar to the temporary boot device selection menu of most recent BIOSes.
2. When you have selected the device to boot from, it looks into its EFI System partition, identified by its type GUID, as FAT file system, and executes a boot loader from a file at a specific path: /efi/boot/bootx64.efi (on amd64 platforms) by default, specially for removable devices.
3. Once the boot loader is loaded, the boot process continues as usual and is no longer specific to EFI (although the ABI used by the boot loader is specific, of course).

It is worth mentioning that the boot manager configuration, which lies in the EFI NVRAM, can be accessed and modified from an operating system, to add random entries for loading a boot loader at any path accessible from the boot manager (you will not be able to load a file from an Ext4 file system, for instance). GRUB on EFI To be able to install GRUB on EFI you need an EFI System partition, formatted in FAT and mounted on /boot/efi. GRUB will simply install itself on /boot/efi/efi/debian/grubx64.efi (on Debian) according to the EFI Specification, and use efibootmgr to create a new boot manager entry called debian and pointing to it. Tricks Well, for me, it did not work. The debian boot option failed, saying that this was not a bootable disk. I managed to get an EFI Shell, by putting Tianocore's shell into a FAT-formatted USB stick as /boot/efi/efi/boot/bootx64.efi. Using this DOS-smelling shell, I found that the directory /efi was unusable: it was listed, but any command trying to access to it failed. The reason was quite tricky, caused by a broken FAT implementation. With FAT, the file system label is stored both in the file system header and as a bogus root directory entry (yes, this sounds completely crazy). As I labelled my EFI System partition as EFI , there was such a bogus entry for this name: I think ASUS' implementation of FAT was taking it for the /efi directory. It took me hours to finally find the cause of this problem and fix it be re-formatting the partition with a new label (re-labelling may have been sufficient but I wanted to be safe).